Problem

Activity.finishAffinity() throws IllegalStateException("Can not be called to deliver a result") when the activity's result code isn't RESULT_CANCELED or it has result data. openPlayStoreLink() is called from fragments hosted by a wide range of activities, several of which set a result — so the host can have one pending.

#22838 tried to fix this by guarding on isFinishing/isDestroyed. That's orthogonal to the precondition AOSP actually checks, so it was a no-op: the crash continued through 26.8 and 26.9 and is still present in 27.0 (~239 users across the three Sentry groups). This clears the result before finishing instead, plus a finish() fallback for the remaining embedded-activity throw path.

Sentry: WORDPRESS-ANDROID-3F23, WORDPRESS-ANDROID-3F1V, WORDPRESS-ANDROID-3F3X

Verified end to end

Reproduced and fixed on a Pixel 8 / API 35 emulator. Two temporary local edits were needed to reach the code path (neither is in this PR): pointing JETPACK_PACKAGE_NAME at com.jetpack.android.prealpha so a debug Jetpack install counts as installed, and adding requireActivity().setResult(RESULT_OK, Intent()) in JetpackStaticPosterFragment.onViewCreated to give the host a pending result.

Before the fix — WordPress app → Reader tab (JetpackStaticPoster) → "Switch to the Jetpack app":

java.lang.IllegalStateException: Can not be called to deliver a result
	at android.app.Activity.finishAffinity(Activity.java:7350)
	at org.wordpress.android.ui.ActivityLauncherWrapper.preventBackNavigation(ActivityLauncherWrapper.kt:81)
	at org.wordpress.android.ui.ActivityLauncherWrapper.openPlayStoreLink(ActivityLauncherWrapper.kt:53)
	at ...JetpackStaticPosterFragment.observeEvents$lambda$0(JetpackStaticPosterFragment.kt:64)

Same frames as WORDPRESS-ANDROID-3F23 (line numbers differ by the 3 added lines; Activity.java:7350 vs 7150 is the API level).

After the fix, same steps: 0 fatal exceptions, Jetpack in the foreground, 0 remaining WordPress activity records (the task was finished), and Back goes to the launcher rather than WordPress — so the feature's intent is preserved. The catch fallback did not fire, meaning finishAffinity() itself succeeded rather than being rescued.

Still open

1. Side effect. Clearing the result is a behavior change. finishAffinity() only finishes activities sharing this affinity, so an activity in a different task that started this one for a result now receives RESULT_CANCELED instead of whatever was pending. That looks right for a "hand the user to Jetpack and tear down the task" flow, but I haven't proven no caller depends on it. This is the part worth reviewing.
2. No automated regression test. The unit tests mock Activity, so finishAffinity() is a stub and they cannot exercise this precondition — exactly why Fix Sentry WORDPRESS-ANDROID-3F23: guard preventBackNavigation #22838 shipped green. A real-Activity instrumented test would catch it, but androidTest doesn't compile on trunk in three independent pre-existing places (MySitesPage.kt Matchers.isA<Any>(...) type mismatch, MySitesPage.kt unresolved R.id.quick_link_item, BaseTest.java:49 createComposeRule signature). I left that test out rather than ship code I couldn't compile.
3. The production trigger is still unidentified. My repro manufactures the pending result. Every setResult I found on a reachable host is immediately followed by finish(), which the existing isFinishing guard already short-circuits; the only long-lived one is ReaderPostListFragment.onAttach(), which can't run in the WordPress app because the poster replaces the Reader. So something sets a result on these hosts by a path I haven't found. The fix is unconditional and doesn't depend on knowing it, but it means we can't yet write a test that fails for the real reason.

Testing

./gradlew :WordPress:testWordPressDebugUnitTest --tests "*ActivityLauncherWrapperTest*" — 8/8 pass. The two new cases assert setResult(RESULT_CANCELED, null) runs before finishAffinity(), and that an IllegalStateException from finishAffinity() falls back to finish() instead of propagating.

Follow-ups

• androidTest is broken on trunk (see above) — worth fixing independently.
• ReaderPostListFragment.onAttach() sets RESULT_OK unconditionally on its host, whether or not anything changed.